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(57) Abstract 

An apparatus and method for processing health care transactions through a common interface in a distributed computing environment 
using specialized remote procedure calls. The distributed computing environment includes a user interface tier for collecting user inputs 
and presenting transaction outputs, a data access tier for data storage and retrieval of health care transaction infoimation, a transaction logic 
tier for applying a predetermined set of transaction procedures to user inputs and health care transaction information resulting in transaction 
output, an electronic network connecting the user interface tier, data access tier and transaction logic tier to each other and a communication 
interface for exchanging health care transaction information among the tiers. The communication interface includes an interface definition 
language generating transaction-specific communication codes whereby data is exchanged through a common interface structure regardless 
of the origin of the data. 
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METHOD AND APPARATUS FOR PROCESSING HEALTH CARE 
TRANSACTIONS THROUGH A COMMON INTERFACE IN A 
DISTRIBUTED COMPUTING ENVIRONMENT 

5 Field of the Invention 

The present invention relates generally to the field of 
computer-implemented data processing systems. More specifically, the 
present invention is directed to an apparatus and method for processing 
health care transactions through a common interface in a distributed 
10 computing environment. 


Background of the Invention 


The use of computer systems to process health care 

15 transactions is widespread. This is the problem. Each generator of health 
care transactions stores information 'particular to its needs in a database 
format optimized for its processes in a computer environment developed 
from its technical skill level, growth and history. 

For example, hospitals store a wealth of information on each 

20 patient, health care provider and medical intervention occurring within 
its walls. Hospitals store information such as, for example, in-patient and 
out-patient records (including patient charts), doctor privileges, nurse care 
schedules, operating room schedules and equipment inventories. 
Traditionally, hospitals transmit only as much of this information to 

25 health care insurers as needed to be reimbursed for health care costs. 

In another example, physician offices also keep electronic 
records on each patient. Such information may include patient's personal 
data, patient immunization records, patient health history records and 
details about each patient visit. Again, health care providers typically 

30 transmit only as much of this information to health care insurers as 
needed to be reimbursed for health care costs. 

In another example, dental offices also keep electronic records 
on each patient. Such information may include patient's personal data. 
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patient dental cleaning history, records of upcon\ing appointments, 
patient health history records and details about each patient visit. Again, 
dental care providers typically transmit only as much of this information 
to health care insurers as needed to be reimbursed for dental care costs. 
5 In yet another example, pharmacies keep electronic records 

concerning patient prescriptions, patient allergies and patient personal 
data. Again, pharmacies typically transmit only as much of this 
information to health care insurers as needed to be reimbursed for 
pharmacy costs. 

10 The information requesting reimbursement for health care 

provided to a patient typically is transferred to the health care insurer in 
the form of a claim. The exact format of a claim takes many different 
electronic forms depending on the entity that generates the claim. A 
health care provider entity may be, for example, a hospital, physician 

15 office, dentist office or pharmacy. In addition, some claims pass through 
third party claims clearinghouses before being accepted by the health care 
insurer which may further change their electronic format. Payment 
obligations may pass to claims clearinghouses, other insurers, or a 
financial institution. 

20 The data transfer itself may occur through very different 

transfer protocols and data error detection processes resulting in 
transforming data into even different formats. 

The difficulty of communicating among different types of 
information stored in different electronic structures in different electronic 

25 environments is compounded when that information may be encrypted 
and /or compressed as well using different encryption and compression 
schemes. 

In addition, the information itself may be stored in different 
human languages. Claims generating from a hospital in France are 
30 written in French in addition to the French data being encoded in a 
different database format in a different computer environment. For 
example, the common format for recording a date in the United States is 
month/day/year but in Europe, the common format is day •month* year. 

2. 
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Though a perhaps minor difference, the erroneous transposition of the 
month and day in a data format would seriously undermine the integrity 
of all the records of an entire file. 

There is a continued need for a system capable of 
5 communicating between a multiplicity of different computer 
environments. 

Summary of the Invention 

The present invention is an apparatus and method for 
processing health care transactions through a common interface in a 
distributed computing environment. In particular, the present invention 
provides seamless communication between different computer systems 
and the data stored within each system through the use of specialized 
remote procedure calls. 

It is a primary objective of the present invention to provide a 
common interface structure for processing health care transactions, 
regardless of the data's native format, compression, encryption, native 
language, country of origin, or operating environment of origin. 

It is another objective of this invention to minimize 
computing time and resources in processing health care transactions. 

It is a further objective of this invention to provide flexible 
system architecture for processing health care transactions in a constantly 
changing world. 

Brief Description of the Drawings 

Figure lA is a block diagram showing the computer 
processing system of the preferred embodiment of the present invention. 
30 Figure lb is a block diagram showing the computer processing 

system of an alternate embodiment of the present invention. 

Figure 2 is a block diagram showing different subsystems 
operating with the computer processing architecture depicted in Figure 1. 
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Figure 3 is an illustration of example service requests 
generated in accordance with the present invention. 

Figure 4 is a flov^chart describing the general method for 
processing client and server stubs. 
5 Figure 5 is a flov^chart describing the general method for 

processing health care transactions in accordance with the present 
invention. 

Figure 6 is a flowchart depicting the Validation step of Figure 
5 in greater detail. 

10 Figure 7 is a user interface screen depicting user entry of data 

in the provider contracting subsystem. 

Figure 8 is a user interface screen depicting entry of a data 
request in the provider contracting subsystem. 

Figure 9 is a user interface screen depicting the on-line 
15 response to the data request of Figure 8. 

Figure 10 is a block diagram showing the logical relationships 
among data within the provider contracting subsystem. 

Figure 11 is a block diagram of the member enrollment 

subsystem. 

20 

Detailed Description of th e Invention 

The present invention provides a system for processing 
health care transactions in response to a user's request in a heterogeneous 
25 computing network. This is accomplished with an international manage 
care administrative system architecture. 

The preferred embodiment of the present invention is 
implemented in a heterogeneous computer network environment that 
divides applications into parts or tiers that can be run independently on 
30 multiple systems that are connected via a network. More specifically, 
referring now to the drawings, wherein like reference numerals denote 
like elements throughout the several views, Figures lA and IB show 
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block diagrams of a computer network 10 including several networked 
systems 12. 

The applications 14 operating within systems 12 are 
developed using a three-tiered architecture. Each network system 12 
5 implements apphcations 14 including a user interface tier 16, business 
logic tier 18, data access tier 20 and communication interface 22. The 
systems 12 are connected through a network cormection 24. 

Each application tier 16, 18, 20 may be implemented on a 
separate computer system 24 within the network system 12 such as shown 
10 in Figure lA. The computer system 12 running one application tier may 
be completely different from the computer system on which another tier is 
running. In the preferred embodiment, referring to Figure lA, each 
application tier 16, 18, 20 is implemented on an independent computer 
system 12 networked in a client /server environment. In an alternated 
15 embodiment, one or more of the application tiers 16, 18, 20 may be 
running in the same computer system 12 as shown in Figure IB. 

In the context of this disclosure, the systems 12 to which the 
terms client and server are attached include programs that are running on 
some machine connected to a network. More specifically, a "server" is a 
20 program that advertises services it is capable of providing and a "client" is 
any program that requests services from one or more servers. In many 
cases a server is also a client of other servers in the network 10. 

In the preferred embodiment, user interface tier 16 is 
implemented on a personal computer .providing a graphical user interface 
25 (GUI). More specifically, in the preferred embodiment, the personal 
computer functions under an operating system consistent with Microsoft 
Windows operating system standards and is configured, at a minimum, 
with an Intel '386 processor chip or its equivalent and 8 MB RAM. 

Business logic tier 18 is implemented on a server system in 
30 the preferred embodiment. It is understood that the server system may be 
a computer system 12 of any size from personal computer to mainframe to 
supercomputer depending on the computer resources required. In the 
preferred embodiment, the business logic server system is implemented 
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on Unix computer systems, such as, IBM RS/ 6000 running AIX 3.2.5 and 
programmed in ANSI C and SQL (Structured Query Language). 

Data access tier 20 is implemented in a database system. It is 
understood that the database system can be maintained in a computer 
5 system 12 of any size from personal computer to supercomputer, 
depending on the nature and volume of the data stored. In the preferred 
embodiment, the database system is a relational database server utilizing 
SQL for database access, such as the one vended by Sybase Corporation, in a 
UNIX operating environment. 
10 The use of the three-tiered architecture accommodates the 

scalability of applications. Desired functionality extends to operate on a 
number of computer systems 12 throughout the network. Portability of 
applications from one system 12 to another is enhanced within the three- 
tiered architecture of the distributed computer network environment 
15 because of the modular structure of the applications. The modular design 
encapsulates each application 14 and its operation such that much of the 
application's operation and implementation information is hidden from a 
user. Each application 14 uses an interface to present its abstractions 
cleanly with no extraneous implementation information. Thus, 
20 applications are scalable to the environment in which they reside as long 
as a clean interface is maintained. 

Communication interface 22 provides the standard 
mechanism for inter-tier communication. Rigorous definition of the 
communication interface 22 allows one tier of an application to be replaced 
25 without effecting other tiers. The replaced portion of the application is 
kept current with the latest technologies without requiring rewriting of an 
entire application each time one part is upgraded. For example, the user 
interface tier 16 can be independently replaced with a different technology 
or system 12 without affecting the business logic 18 or data access 20 tiers. 
30 In the preferred embodiment, communication interface 22 is 

implemented via remote procedure calls (RPCs). The RPCs are 
implemented through the use of Open Environment Corporation's (OEC) 
Entera product consistent with Open Software Foundation's Distributed 
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Computing Environment (DCE). DCE defines a vendor-independent 
definition of RFC communication in a heterogeneous, distributed 
network. Use of DCE provides a robust, open systems definition for 
client/server communications. In the preferred embodiment, the 
5 communication interface 22 transfers data among the tiers 16, 18, 20 over 
standard TCP/IP (Transmission Control Protocol/Internet Protocol) 
connections. Tiers 16, 18, 20 provide processing for health care 
transactions. 

Referring to Figure 2, health care transactions can originate 
10 from many different sources or clients, such as, for example, enrollment 
subsystems 26, billing subsystems 28, benefits subsystems 30, provider 
contracting subsystems 32,provider network management 34, claims 
processing subsystems 36, security and authorization subsystems 38, check 
processing subsystems 40, customer service subsystems 42, case 
15 management subsystems 44, cost containment subsystems 46, provider 
electronic data interchange (EDI) subsystems 48 and /or browser subsystems 
50. It is understood that each subsystem 26-50 may be maintained on 
completely different computer hardware systems from the other 
subsystems. Each hardware configuration operates with its own operating 
20 system environment storing information in potentially widely varying 
data formats. 

Depending on the health care transaction processed, the client 
request for the transaction service is sent to an appropriate server for the 
requested information. Servers include, for example, the business logic 

25 tier 18 and data access tier 20 of the enrollment subsystems 26, billing 
subsystems 28, benefits subsystems 30, provider contracting subsystems 
32,provider network management 34, claims processing subsystems 36, 
security and authorization subsystems 38, check processing subsystems 40, 
customer service subsystems 42, and case management subsystems 44. 

30 The requests for transaction service are generally 

implemented as remote procedure calls (RPCs). Remote procedure calls 
are ideally suited to handling multiplicity of health care transactions. 
Once modified to handle health care transactions, RPCs provide a method 
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for communication among systems with very different types of data 
maintained in very different formats and computing environments while 
maintaining the integrity and character of that data. Though the client 
request is generated in one computer system 12 or subsystem 26-50 and the 

5 requested information lies within another computer system 12 or 
subsystem 26-50, the communication interface 22 provides a common 
interface for completing the transaction service requested by the RFC. 

More specifically, referring to Figure 3, as each application 
within tier 16, 18, 20 is added to network 10, an interface communication 

10 file 52 is created for each client program 54 and each remote server 
procedure 56. The interface communication file 52 generates 
communications code 58. The generated communications code 58 is 
referred to as client stubs 60 and server stubs 62. In the preferred 
embodiment, client stub 60 and server stub 62 are incorporated into 

15 applications 54, 56. With OEC Entera product, client stubs 60 are generated 
in PowerBuilder'rM, c, or perl, depending on the need. Server stubs 62 are 
generated in C and perl. 

Use of a common communication interface 22 in the system 
architecture of the present invention enables the use of open systems 

20 technologies, adherence to international data processing standards and 
internationalization standards while utilizing an architecture that 
promotes vendor independence. This distributed computing model can 
operate in both a local area network as well as over a wide-area network or 
over the Internet. 

25 In the preferred embodiment, the RPCs have been modified 

to generate health care transaction-specific client stubs 60 and server stubs 
62. The client and server stubs generators 52 are incorporated into 
applications during the compilation process. More specifically, the 
incorporation process occurs automatically through the use of specialized 

30 compilation tools. 

In particular, the specialized compilation tools have been 
implemented as a set of makefile templates for use in building servers. 
The makefile templates primarily contain macro definitions for the UNIX 
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MAKE facility. These definitions provide information required by MAKE 
to compile and package a server. Sample makefile templates with 
common rules to build servers and clients are included in Appendix A. 

It is understood that the contents of any macro will change 

5 depending on the application developed. For example, typical macros in 
the makefile templates include macros named SERVER, DB_NAME, 
APPL.NAME. The SERVER macro defines the name of the server. The 
DB_NAME macro defines the name of the database to be accessed by an 
SQL server. The APPL_NAME macro defines the name of the application. 

10 The particular macros used and the values assigned to them vary 
according to the type of server. For example, a server build in an SQL 
environment with C code uses one makefile template while a server built 
with embedded SQL requires a different template and a server built using 
C code uses a different template. 

15 Once a server is built and logged on to the network 10, the 

server is ready to process requests from a client. The type of requests that 
the server will process depends on whether the server supports 
applications 14 for the user interface tier 16, business logic tier 18 or data 
access tier 20. 

20 In operation, when a client makes a request for a service from 

a server, communication interface 22 provides the information to the 
server in the format that it requires to perform the service requested. 
More specifically, the communication interface 22 connects the cUent with 
the appropriate server and passes information between the server and 

25 client through client /server stubs 60, 62 generated during the request 
process. The client/server stubs 60, 62 are generated from interface 
specifications 52 coded during the compilation process according to the 
. makefile templates. This generated stub code insulates the application 
developer from the underlying complexities of network programming. 

30 Referring to Figures 3-6, the request process is initiated when 

a client makes a request for service (step 100 of Figure 4). Typically, the 
request is initiated as an ordinary function call in the operation of the 
client application. For example, referring to Figure 3, the client program 54 
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requests membership information 64. For convenience, the reference 
numbers of the elements of Figure 3 will be used to aid in the description, 
however, it is understood that the example depicted in Figure 3 is only an 
example and that many other types of requests are made within a health 

5 care transaction network 10. For example, request 64 for member 
enrollment information may be made by program 54 in the benefit 
subsystem 30. The benefit subsystem 30 holds information regarding 
benefit plans. Benefit plans define what services are covered and at what 
level each service is covered. Following this example and referring to 

10 Figure 3, the benefit subsystem 30 is the client and the enrollment 
subsystem 26 is the server. Broadly, enrollment subsystem 26 processes 
benefit subsystem's 30 client request for member enrollment information 
and returns the information to benefit subsystem 30 appended to server 
stubs 62. 

15 Referring to Figure 4 for general functionality, client 

application makes a service request 64 (step 100). Client stub 60 is 
generated (step 102). Client stub 60 includes information for the remote 
procedure call, handling of input arguments and understanding of the 
client/server context. 

20 Next, the client stub 60 locates the appropriate server to 

handle the request (step 104). If the client does not know the location of 
the appropriate server, client stub 60 queries a directory server for the list 
of locations (hostnames and ports) where a server is available. The 
directory server listens for client requests and maintain a list of locations 

25 of servers registered with the directory server. In response to the client 
stub 60 query, directory server returns the address(es) of available servers 
in the network 10. The client stub 60 caches the server address(es) for 
future requests and for redundancy purposes. If the address of the 
appropriate server is already cached, client stub 60 uses the cached 

30 information to locate the server. 

After client stub 60 has located a server (step 104), it sends the 
client input arguments through the network 10 to its corresponding server 
stub 62 (step 106). The input arguments typically include a security ticket 

10 
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validating the client. The server then processes the request (step 108). 
More specifically, server stub 62 unpacks the input arguments and calls the 
function desired by the client application. For example, in Figure 3, server 
program function 66 checks on membership status. Server function 66 
5 returns output arguments (and any error parameters) to the server stub 62 
which passes them back to the client stub 60 (step 110). Client stub 60 
processes response to the request (step 112). More specifically, the client 
stub 60 unpacks the output arguments and returns them to the client 
application (step 112). 

10 It is understood that whether the process is defined as a client 

process or a server process depends on the context and perspective of the 
client and server. For example, a server can make requests to other 
servers, making the process both a server and a client process. Generally, 
client stubs 60 are responsible for locating a server to handle the request, 

15 packaging input arguments and passing them over the network 10 to the 
server with the validation ticket, waiting for the server to reply and 
unpacking the return value and output arguments returned by the server. 
Server stubs 62 are responsible for listening for client requests, unpacking 
the input arguments, validating server access, calling server function, 

20 packaging the return value and output arguments returned by the server 
code, recording audit information, gathering performance data and passing 
return value and output arguments back to client stub 60 over network 10. 

Referring to Figure 5, when a client first makes a request, the 
network 10 first checks that the client is valid (step 114). Once the client is 

25 validated, the client requests can be sent through the network 10 (step 116) 
for processing by a server (step 118) to receive the appropriate output (step 
120). 

Referring to Figure 6, the validation step 114 of Figure 5 is 

depicted in greater detail. VaUdation step 114 starts by verifying that the 

30 client is connected to the network 10 (step 122). Then, network 10 checks 

that the client has been authenticated (step 124). More specifically, the 

network 10 checks whether the client has a valid ticket to request network 

services. The client stub must present a valid network-generated ticket 
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when making a service request. Those skilled in the art will recognize that 
the form and contents of a valid ticket may vary depending on the security 
requirements of network 10. 

Once the network 10 authenticates the client, the server 

5 checks whether or not the chent is authorized to use the interfaces in the 
server (step 126). More specifically, the server verifies that the specified 
user is a member of a group that has permissions to perform the requested 
operation by comparing the ticket contents against the server's own 
database access control information. 

10 Examples of the specific types of requests made and data 

flowing through a health care transaction network 10 are shown in Figures 
7-11. Figures 7-10 show the provider contracting subsystem 32 which 
provides data management functions to build and maintain provider 
contracting definitions. Definitions managed within the provider 

15 contracting subsystem 32 include, for example, information about: health 
care providers, including physicians, hospitals and dentists; 
reimbursement agreements between providers and a company; effective 
dates; contracting entity; contracting companies; fee schedules and rates; 
rate type, such as, per diem, per hour, per stay, percentage; fee maximums; 

20 procedure codes; hospital categories; government health care program 
information, such as. Medicaid and Medicare; and data relating to costs 
associated with a medical service but for which a claim has not yet been 
received. 

More specifically, for example, for the fee schedule, the data 
25 captured is the rate schedules used by the providers. In particular, the 
information stored includes a unique id for the fee schedule, a free form 
description of the schedule, the procedures and maximum fee rates for 
each procedure code covered in a fee schedule, and a resource based 
relative value scale rate (pre-determined). 
30 The data may be entered in different formats. In the preferred 

embodiment, the data is entered as shown in Figure 7. For example, 
demographic parameters for a particular health care procedure code 
include the type of procedure 130, specific procedure code 132, text 
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description of procedure code 134, the effective and expiration dates for the 

use of procedure code 136, any gender limitation for procedure 138, any age 

limitation for the procedure entered as the limits of an age range 140 and 

information as to whether additional description is required 142. The 

5 specific procedure code is obtained from standard listing of procedure 

codes updated annually by national medical and insurance associations. 

Different demographic parameters are required for dental procedures 144. 

Requests for procedure code fee schedule information are 

made as shown in Figure 8. Procedure code information can be obtained 

10 by searching for a given procedure type 130, a particular procedure code or 

range of procedure codes 132 and/or procedure description 134. Procedure 

code fee information is returned, as shown, for example, in Figure 9. In 

Figure 9 the information is sorted by contract unit 146 and fee schedule 

148. Procedure code data is stored in a database system. It is understood 

15 that the database system may be a single database system or different 

database systems. Figure 10 shows the interconnectiveness of the data, its 

general storage and access relation to other files. Appendix B provides an 

example data dictionary listing variable names and descriptions. 

In another example, enrollment subsystem 26 establishes and 

20 maintains individual membership health care plan enrollment records. 

Referring to Figure 11, first a contract for managed care services is signed 

between an account and a managed care organization (step 150). An 

account may be an individual, family or company. Next, the contract 

information is entered into the subsystem 26 (step 152). Next, enrollment 

25 form information, provided by each individual member, is entered into 

the subsystem 26 (step 154). Enrollment additions, changes and terms are 

each entered as a transaction to the enrollment subsystem 26 (step 156). 

Enrollment information is retrieved from the enrollment subsystem 26 as 

needed by other subsystems such as, for example, the benefit subsystem 30. 

30 Although the description of the preferred embodiment has 

been presented, it is contemplated that various changes could be made 

without deviating from the spirit of the present invention. Accordingly, it 

is intended that the scope of the present invention be dictated by the 

\3 
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appended claims, rather than by the description of the preferred 
embodiment. 
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# $Id: Makefile, V 1.6 1996/12/11 19:26:16 tnbell Exp $ 
# 

# Copyright UNITED HEALTHCARE CORPORATION 1995. 

This software and documentation contain confidential and 

# nroorietarv information owned by United Healthcare Corporation. 

# unauthorized use and distribution are prohibited. 

H Sample makefile to be used for servers generated via tpmake. 

a vi:set tabstop=8 : , - . r-n 

^ Specify the name of the server. Ths server bxnsry will ce ler-. m a file 

^ v;ith this name . 

PROD_aSER= 'whoami ' 

SERVER = fee_qu=ry 

a The SQL PREFIX macro has been left co facilitate us2 of both 1.0 and 

# l.'l versions of the OEC tools, It's function has been replaced by 

# the SQL macro. 

SQL^PREFIX = fsched^query 

# The SQL, DB_NAME, DB_TYPE, DB_LOGIN, and DE_PWD macros are used to build 

# the $ (SERVER) .res file required by tpmake. 
# 

# SQL - Specifies the name of a file containing SQL statements. The fxle 

# name must end with a .sql suffix. A C source file will be created 

# for each SQL file. These files will have names that correspond 

# with the SQL file names (e.g., queries. sql results in queries. c 

# being generated) . 

# DB_NAME - Specifies the name of the database to be accessed by the 

# statements in the corresponding SQL file. 
# 

# DB TYPE - Specifies the type of DBMS where the database resides. This 

# " must be one of the following: 

# db2 - DB2/6000 

# Sybase - SYBASE 
# 

# DB LOGIN - Specifies the name of a shell environment variable that will 

# " contain the login id used to access the database. 
# 

# DB_PWD - Specifies the name of a shell environment variable that will 

# contain the password used to access the database. 
# 

# NOTE: The 1.1 version Of the tools allows a single server to access 

# multiple databases. If your server needs to do this, specify multiple 

# values for each of thes macros. For example: 
ft 

^ SQL = syb_queries . sql db2_querxes . sql 

# DB_N.AME = claims calls 
if DB TYPE = Sybase db2. 

# DB]2lOGIN = SYB_LOGIN DB2_L0GIN 

# DB PWD = SYB_PWD DB2_PWD 

# The number of values specified for each of these macros must match. 

SQL = $ (SQL^PREFIX) , sql 

DB_NAME = 'getenv("DB__NAME'*) ' 

DB TYPE = Sybase 

DB"L0GIN = DB LOGIN 


wo 98/35284 PCT/US98/02372 


A - 2- 

DB_PWD = DB_PWD 

SQL TAGS = .$ (SQL: .sql=) 

SQL^C = $ (SQL,: .sql=:.C) 

SQL"DEF = $ (SQL: .sql:=.def ) 

# Specify the test client name. If there is no test client 

^ (e.g., rpcdebug is used for testing the server), specify the keyword 
U "none". 

CLIENT « none 

# Specify names of all IDL files that should be cornbined to form the 

?i IDL definitions for this server. The niakefils vili m.ergc the specified 

# files into the file $ (SERVER) .def . Therefore, you must not have hand 
if ceded IDL definitions in a file naxed p (SERVER) .def . 

# 

?i Some commonly used definitions for IDL_SRC£ are: 
U IDL_SRCS = $(SQL_DEF) 

# All IDL definitions are generated from SQL via sqlmake. 
# 

# IDL^SRCS = my.def 
1^ 

# All the IDL definitions for the server have been hand coded. No 

# IDL definnitions will be generated from the SQL definitions. 
# 

# 1DL_SRCS = my.def $(SQL_DEF) 

# The hand coded IDL will be merged with IDL generated by sqlmake 

# to create the server's IDL definitions. 

IDL_SRCS = fs_query.def 

# Specify the version identifier to place in the generated IDL file. 

# NOTE; This may not be left blank 
IDL_VERSION =1.0 

ft The DATABASE macro has been left to facilitate use of both 1.0 and 
#1.1 versions of the OEC tools. It's function has been replaced by 

# the DB_NAME macro. 

DATABASE = newunity 

# Specify the name of the application as it appears in the authentication 

# maps. This value is used by the code generated to validate application 

# tickets. If this server does Aot require application tickets, leave the 

# application name blank. 

t 

APPL^NAME = unty 

# Specify the type of ticket required. This must be either global_ticket 

# or appl_ticket, 

TKT__TYPE = appl_ticket 
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^3 

a Specify the name of a global string variable that will hold the ticket 
fi that may be required to access functions in the server. If none of the 
fi server functions require ticket validation, this can be left blank. 

ii NOTE: PowerBuilder applications will have to manually declare this global 
variable. 

t:-:t name ■ g_sSec_appltkt 

^ List all server functions that do not require ticket authentication. 
^ The default is to require a valid ticket for access. Specify the 
^ keyword "all" to prevent the addition of cickec handling code. 
a 

MOTE; If vcu will h-zL cestir.g the servar via rpcdcbug, ycu nust specify 

4 NO TICK^T«all v/hen building the tesn server. This can b^=: done nr. 
*-he T.ake ccnxar.d line; there is no need tc chang= t'r.e :*.:a>:efile 

E to build a test ser-zer (e.g., make ITO_TlC?:ET-all) . 

NO_TICKET 

# If you want to turn error logging on for this server, specify the 

# keyword "yes". Otherwise leave it blank, the default here. 

2RR0R_L0GGING = yes 
ESCAPEQUOTES on 

i$ To use message catalogs, place the prefix name of the message source 
1^ file here. The prefix name is the same as the Unity subsystem prerixes. 

# i.e. ben, enr ... The message source file and the message Makefile 

# should alreadv be placed in a subdirectory of the same prefix name 

# in the path ($WORK_ROOT) /unity /msg . 

# {e.a. for the subsystem prefix name "xyz" ) 

if 

# "$(WORK ROOT) /unity/msg/xyz/xyz.msg" where the 

5 message'source file name is xyz.msg and 
H MESSAGES = xyz . 

u 

# Add the following definition file format in - 

# the server's include list: 
^ # include "xy2__msg.h" 

# 

# Refer to ($WORK_ROOT) /unity/msg/README for more information. 

# Be sure the WORK_ROOT environment setting is set to "$ HOME/ work " . 
ItESSAGES = prv 

MSSSAGES_H = $ (MESSAGES : =_msg .h) 

# List any functions that require auditing. If the keyword "all" is 

# specified, fevery function call will be audited. By default, fxmctions 

# will not be audited. 

AUDIT 

# Specify the name of a function to be called during server initialization. 

# If you do not need a function called during server initialization, leave 

n 
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if this blank. |A 
# 

if NOTE: Servers generated by tpmake include a function named $ (SERVER) _inic 
fr that must be called to initialize the server. If you change the 

iz SRVR_MAIN definition to call your own inicialization function, 

# your function must call $ (SERVER) _init . 

^ NOTE: This macro is not used by the 1.0 build process. 
SRVR^r^AIN « init_nls_func 

^ Specify the name of a function zo be called during server shutdown, 
if If you"dc not need a function called during server shutdc-n, leave 
i; this biark. 

NCTE: Servers gen^iruCed by cpnalce include a functio:- -B-^t $ (SERVER) _e:-d 

# that must be called to cleanup the server. If ycu change the 

# SRVR__CLEANUP definition to call your cv;n clenaup function, your 

# function must call $ (SERVER) _end. 

^ NOTE: This macro is not used by the 1.0 build process. 
SRVR^CIjEANUP $ (SERVER) _end 

# Soecify types of server and client stubs to be generated. 

# currently build C server stubs, C client stubs, PowerBuilder client stubs, 

# and Perl client stubs. 

SRVR_STUB = $ (SERVER)_S,C 

CLOT STUBS = $ (SERVER) _c.c \ 

$ ( SERVER) „C. pi 

# Specify the source files that make up the server. 

u 

# NOTE: Do not remove the reference to transac.c; it is required for 

# code generated by tpmaJce. 

SRVR^SRCS a \ 

" fs_query.c \ 

$ (SRVR_STUB) \ 
$(SQL_C) \ 
transac.c \ 
f s_query_nls.c 

# Specify the components that make up the client (if there is one) . 

CLNT^SRCS = $ (CLIENT). c \ 

$ (SERVER) _C.C 

# Specify any man pages to be installed with this server. 
MANPAGES = $( SERVER). 1 

S Specify the^top of the installation directory. The install target is 

# set up to install files relative to this directory. The default is 

# correct for most servers . 

WHEREIGO = $ (DESTROOT) /usr/dce 

MANDIR = $ (DESTROOT) /usr/man/manl 
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S Define the list of object files needed for the server and client.. 

# The default is correct for all servers. 

SRVR OB JS = ? ( SRVR_SRCS : . C= . o) 

CLNT~OB JS = $ ( CLNT_SRCS : . C= . o) 

# Define options used on cc commands. The default is correct for most 
if servers . 

I NOTE- TO comoil- the program with debug tables, specify ••MAXO?T=-g" on the 
I ^Ike coJvm^nd. The macro allows you to specify other options 

ji and to override default options when necessary. 

N:?J{OPT = -g 

n=•T^T^TPc; = S (DCK DEFINES) ,. , 

. ll^r--'--Trj^vs\ -l$ (i:s DCE TOOLS) /include- 

rr^DT^S : i 5ci-:i3 DIRS) -L$ (HCdCsZtOOLS) /lib 5; L0CAL LIB OPTIOM 

CFLAGS ,= $ (MAXOFT)-$ (DEFINES) ${1NCLUDS) $ (I.I3DIR3) ? f.EZF^^GS) 

# List of libraries to be searched when loading the server or client. 
t NOTE: You must not remove either of the default values. 

LIBS = $(SYBASE_LIB) $(DC3_LIBS) $(DNTY_LIBS) $ (LOCAL_LIB_NAME) 

# Rules for required targets. 

all: $ (MESS.AGES_K) stubs client server 

^''^"^^^'$aisTAI.L_SERVSR) $ (SERVES) $ (IDL_VERSION) $ (WHEREIGO) 
touch $ (SERVER). 1 

$(IjSISTALL_MAN_PAGES) ${MANDIR) $(MANPAGES) 

rm -rf $ (SQL_C) '$(SQL PREFIX) .h $ (SERVER) _funcs .h transac-c 
rm -rf $ (SRVR OBJS) $(CLNT_OBJS) 

rm -rf $ (SRVR'STUB) dbras.h warning 

rrn -rf $ (SERVER) .res $ (SERVER) .def $ (SQL_PREFIX) . def 
rm -rf *.time 

''^°^''"'rS^!rf $ (SERVER) $ (CLIENT) $ ( CLNT.STUBS ) $ (SERVER) .h 

server: $ (SERVER) 

these: 

echo $ (MESSAGES_H) 
client: $ (CLIENT) _check 
stubs: $(SRVR_STUB> $ (CLNT_STaBS) 

L0CAL_LIB_OPTION = . -L$ (LOCAL_LIB_DIR) 

LOCAL LIB NAME = -Iprvlib 
L0CAL"LIB' = libprvlib.a 

LOCAlIlIB_DIR = $ (WORK_R00T) /unity/prv/lib 

# Pick up the common macro definitions and make rules 
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inclUCle $ (UHC_DCE_TOOXiS) /incxuae/accj._^wuu»w.* A *U 

iixclude $ (UEC_DCE_TOOLS) /include/dcel^cur rentes tubs 
include $ (UHC"dce_TOOLS) / include /dcel"make_rules 
include $ (UHC_DCE_TOOLS) /include /dee l_sgl_make_rules 

?i Place any server specific dependency rules and/cr targets after this couunent. 

f? The following includes are unity specific. 

include $ (WORK_ilOOT) /unicy/includs/unty_make_rules 
include $ (WORK_ROOT) /unity/inclucle/unty"ccTtimon_def s 

^ These includes are for makeing "generic" servers. 
# Uncoxraent and custcr.iza as required. 

« SUBSVS - your_sub5yst-3iT:;_naTne 

= SQL L03_FZLH = te:<c_filc nar.s_v;hlch ir.cludes_rhose_tabi2s_t'j be "icace 

d - " - " _ - — 

^ SUBSYS_LCG_DTM = the_name_of_che_resulting_dtT._f ile_f or_the_iogQeG_tabl 

es ^ " 

^ include $ (WORK^ROOT) /unity/ include /unty_ctTn_rules 
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Data Dictionary 


Table Name 


Description 


cont_prop 

cont_unit 

contract 

ree__sched 

fees 

fs_by_posla! 
fs_rbrvs 

fs_rvu 
h_bed_type 
h cat detail 


h_cat_header 
h_cont_bed 
h_cont_l ist 

hjDer_diem 

h_per_flat 

hj3er_fs 

hfs_fees 

hfs_grouping 

p_cont_list 

proc_code 

proc_type 
prv_control 

prv_prop_list 


Properties for contracts - i.e. admin, hold. 

Contract Unit Setup Table, This tables defines the valid contract units. 

Contracts header information for physician, hospital and dental contracts. 

Fee schedule header information for physician, hospital and regional fee schedules. 

Physician fee schedules* rates (fee ma.x) by procedure codes. 

Criteria to define the fee schedule associated to regions (by postal code). 

Resource Based Relative Value Master. Contains RBRVS values associated to procedure 

codes and fee schedules. 

Relative Value Master. Contains RVU values associated to procedure codes. 
Global table listing bed types and descriptions. 

Hospital Category Detail. Contains the detail which defines a hospital service code 
category for a contract unit. Used to determine claims payment rates (Hospital 
contracting). 

Hospital Category Header. Contains the hospital service code categories setup for a 
contract unit, used to determine claims payment rates. 

Continuation of the Hospital Contract - lists the bed types and estimates for the bed type 
for IBNR reporting purposes. 

Continuation of the Hospital contract. Contains the "list" of service categories and the 
order to use them (priority). Service Categories for hospital contracts are used to 
determine claims payment rates and rules. 

Continuation of the Hospital contract. Contains the per day/per stay/per hour schedule 
information for hospital contracts (used when h_cont_list.rate_nbr = 1). 
ContinSation of the Hospital contract. Contains the fee schedule information for hospital 
contracts (used when h_cont_list.rate_nbr = 3). . 

Continuation of the Hospital contract. Contains the fee schedule information for hospital 
contracts (used when h_contJist.rate_nbr = 2). 

Hospital Fee Schedule Fees. Contains the fee max for a grouping of procedure codes. 
Used in conjunction with h_per_fs and hfs^grouping. 

Hospital Fee Schedule Groupings. Contains the range of procedure codes assigned to 
groupings. Used in conjunction with h_per_fs and hfs_fces tables. 
Continuation of Physician and Dental contracts. Contains the "list" of fee schedules to use 
and the order to use them (priority). 

Procedure Code Master File. Contains procedure code description and limitations (gender 
and age). 

Global table listing procedure code types and descriptions. 

Global table listing the '"controls" used for processing rules. Currently the only control is 

which property code denotes Administrative Hold for a contract. 

Global table listing the valid property codes and descriptions for provider contracting. 


3-1 
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Column Name 

Attributes 

Description 

cominue_flag 

smallint 

Indicates whether or not to continue looking for other categories to 
match. *0' indicates once the system makes a match, it should not 
continue to look for another category. ' 1 * indicates the system should 
continue to check to see if the claim matches any of the other 
categories. This allows the system to make more than one rate 
payment on the same claim. Valid values are: 

0 - N - no 

1 - Y - yes 
default is 0 

coniiiici riijrnc 


A descriptive name of the contract. 

contract_nbr 

tnt 

The unique identifier for a contract. A contract consists of several 
parameters required for claims payment. The values of the parameters 
when combined make the contract unique. 

contraci_type 

smallint 

Indicates the type of contract, valid values are: 

0 - D - Dental 

1 - H - Hospital 

2 ■ P - Physician (non-hospital and non-dental) 

contraci_unitJd 

char (3) 

A unique id for a contract unit. A contract unit is the entity that 
defines/contracts fee arrangements with a provider net^vork. A contract 
unit can be a business unit or it can be another entity such as HCFA, an 
individual state, a national entity, etc. 

contract_unit_name 

char (40) 

The name of the contract unit. 

country_code 

char (3) 

A short code to uniquely identify- each country. 

db^oper 

char(l) 

Code for the type of database operation, used internally for audit 
purposes. 

desc_reqd_flag 

smallint 

Indicates if a more descriptive procedure description is required at 
claims entry if the procedure code is a generic procedure code. 
Validated against the codeJist,list_id = "yesno" as follows: 

0 - N - no - no description is required 

1 - Y - yes - yes a more descriptive description is required at claims 
entry 

default is 0 

eff_date 

datetime 

The first day the timeline for an entity is active. A timeline represents 
data for a specific date range. 

exp_date 

datetime 

The last day the timeline for an entity is active. A timeline represents 
data for a specific date range. 

ext_name 

char (40) 

Description of categories/services external to the Business 
Unit/Contract Unit. 

factor 

float 

A multiplier used in the contracting subsystem to calculate the fee max 
when using RBRVS. 

fee_max 

float 

The maximum amount a provider may be paid for a specific health care 
service provided to covered person under a specific contract. 

flat_rate 

Hoat 

The rate amount for flat rate contracts. Note all procedures will be 
charged this one amount (if used). 

flal_rate_typc 

smallint 

Indicates if the fiat rate is a per day rate or a rate by procedure. Valid 

values are: 

1 - P - Procedure 

default is 1 

froni_code 

char (20) 

I he lowest value of the data element for a range in the criteria 
i definition. 
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Coiumn Name 

Attributes 

Description 

age_gtrjimit 

smaUini 

Used for age limitation, age greater than the value entered indicates not 
covered procedure code. 

age_less_Iimit 

smallint 

Used for age limitation, age less than value entered indicates not 
covered procedure code. 

approve_date 

daictime 
allow null 

The date the contract was approved by a supervisor and ready co be 
used for claims processing. 

approve^limestamp 

datetime 
allow null 

Date and time the approval was entered. 

_ 

approve_user_id 

cnar 

user_id of the supervisor who approved the contract. 

aut_required 

smallint 

Indicates if an authorization is required for the category. Valid values 
arei 

0 - N - no 

1 - Y - yes 
default is 0 



bed_est_charge 

float 

The estimated charge per day for the bed type. Used for IBNR 
reponins. 

bed_est_type 

smallint 

The type of estimate charge, valid values are: 

0 - D - per diem 

1 - H - per hour 

2 - S - per stay 
default is 0 

bed_type 

char (10) 

Unique identifier for a hospital bed type. 

bed_type_desc 

char (40) 

Description for the hospital bed type. 

calc_nbr 

smallint 

Unique identifier to indicate the formula to use when calculating the 
claim payable amount. Values are validated against code_list table. 

cat_code 

smallint 

A unique key to represent a category of services. Hospital services are 
grouped into a category within the Unity Provider Contracting 
subsystem. Examples of hospital categories are: bum unit, mental 
health/chemical dependency, maternity, etc. 

code_type 

char (5) 

Indicates the type of code range used for a hospital category criteria. 


Example, R indicates the from_code and thru_codc range is a revenue 
code range, A= indicates the from_code and thru_code range is an age 
range where the criteria matches if the patient's age is within the age 
range, etc.. Abbreviations are stored in database. Valid codes are: 

0 - HOS - Hospital Codes 

1 - PS - Patient Status 

2 - PA - Pre-authorizaiion Admit Types 
4 - C - Procedure Codes 

10- ID - Diagnosis Code 

11 - Dl - Primary Diagnosis Code 

1 2 - D2 • Primary or Secondary Diagnosis Code 

1 3 - A= - Patient Age equal to 

1 4 - A> - Patient Age greater than 

1 5 - A< - Patient Age less than 

16 - AC - Claimed Amount e.vcceds 

1$ - ZZ - Default (A default category is always setup on a hospital contract as 
the last priority to establish a default rate for the contract). 


33 
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Column Name 

Attributes 

Description (i. 

percent_of_claimed 

float 

The percent of claimed amount. Used to calculated contract amount 
(amount_claimed • percent_of_cIaimed / 100 = contract amount) or 
lesser of percent of amount claimed or fee max. 

percental 

float 

The percentage amount to pay for the highest dollar procedure (or 
grouping). 

percent_2 

float 

The percentage amount to pay for the second highest dollar procedure 
(or grouping). 

perceni_3 

float 

The percentage amount for the third highest dollar procedure (or 
grouping). 

posiai_from 

char (10) 

The lowest value of a postal code range. 

postalthru 

char (10) 

The highest value of a postal code range. 

priority 

smallint 

The priority given to an entity in a table. The priority establishes the 
search sequence. 

proc couc 


An iH**nriftf>r fnr medical service forocedure^ Procedure codes can be 
CPT codes (Physician's Current Procedural Terminology codes), CDT 
codes (Current Dental Terminology codes), procedure codes unique to 
a country, etc. The combination of procedure code type and procedure 

rr\t\p iHpnftflpc n iininiip nrnfedure 

proc_code_desc 

char (60) 

Free form te.xt description for the procedure code. 

proc_code_from 

cnar (lU) 

I ne lowest value or a proceaure coue range. 

proccodethm 

char (10) 

The highest value of a procedure code range. 

proc_code_type 

char(l) 

The type of procedure code. A procedure code type can be a CPT 
(Physician's Current Procedural Terminology) type. CDT (Current 
Dental Terminology) type, lCD-9 (International Classification of 
Diseases, 9ih edition) procedure type, etc. The combination of 
proceoure cooe type ^proc couc_iypc^ anu pruccuurc couc ^prot_tuuc^ 
identifies a unique procedure. 

proc_rype_desc 

char (30) 

Free form te.Kt description for the procedure code type. 

prop^code 

smallint 

A unique code assigned to a property. Properties establish information 
that pertains to an entity, but does not apply to all entities, (i.e., 
administrative hold, alternate Ids, etc.). 

prop_vaIue 

r*Vt rtr /"i f\\ 

cnar y^v) 

TKa trilit/> nTtKio nmni>rt\/ TVtic vjiliip miilH mnmin whv nn ^nrtrv tc nn 
1 ne vQiuc oi inc propcny. i iiib vatuc tuuiu ^utuutii wny <m ^umjr i* 

3uminiSiniLivc noiu. inc cnuiv :» ducmaic lu. cit. 

rale davs 

smallint 

Indicates the day the rate of payment begins. 

rate nbr 

smallint 

Indicates whether the rates are based on per diem/per stay/per hour or 
based on a fee schedule. Valid values are: 

1 - D - Per Diem (rates based on per diem/per stay/per hour schedule) 
3 - PS - Per Fe? Schedule (rates based on a fee schedule) 
3 - FA - Flat Amount (rates based on a flat rate) 

rate^type 

smallint 

Indicates the type of rate for the category. Valid values are: 

0 - D - per diem (valid for rate_nbr 1) 

1 - H - per hour (valid for rate_nbr I) 

2 - S - per stay (valid for rate_nbr I) 

3 - P - percentage (valid for rate_nbr I and 3) 

4 - A - flat amount (valid for rate_nbr 3) 

rbrvs_flag 

smallint 

Indicates if the fee max value was derived/calculated using RBRVS 



(Resource Based Relative Value Scale). Values are validated against 
code list.list id = "manualsystem". 
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Column Name 

Attributes 

Description 

fs^desc 

char (40) 

A descriptive name for the fee schedule (i.e. Medicare, Medicaid 
Region A, Medicaid Region B» etc.). 

fs_id 

char (5) 

A unique id for a fee schedule. A fee schedule is a listing of codes and 
related services with pre-established payment amounts. 

fs_lookup_rule 

smaliint 

Used to identify how to retrieve (or lookup) fee schedule information. 

1 - P - Physician Fee Schedule 

2 - R - Regional Fee Schedule (also known as National Fee Schedule) 

3 - H - Hospital Fee Schedule 

fs_percenl 

float 

Used to adjust a fee max amount for overhead costs and geographical 
differences. 

fsj3ercentile 

smaliint 

The percentile for the region (i.e. 95ih percentile of the Boston region). 

genderjimil 

smaliint 

Used for gender limitation, values are validated against the 
code list. list Jd = "genderlimit" as follows: 

0 - M - male - indicates the procedure covered for males only 

1 - F - female - indicates the procedure covered for females only 

2 - N indicates the procedure covered for both male and females - no 
limitation 

default is 2 

grouping 

smaliint 

This number is used to group together rows of criteria (hospital 
category criteria). When sening up criteria, rows with the same 
grouping value use "or" logic and rows with different grouping values 
use "and" logic. For example, Revenue code 100 or Revenue code 1 10 
and CPT code 10040 would be set up as follows: 
1 R 100 100 

1 R 110 no 

2 C 10040 10040. 

in_oiit_flag 

smaliint 

identifies whether the category applies to Inpatient claims (I), 
Outpatient claims (0), or both (B) types of claims for the category. 
Valid values are: 

0 - I - inpatient 

1 - 0 - Outpatient 

2 - B - Both 
default is 0 

int_name 

char (40) 

Description of services/categories internal to the Business 
Unit/Contract Unit. 

payment_type 

smaliint 

Defines how the payment is to be made» valid values are: 

0 - F - fee-for-seryice 

1 - C - capitated primary care providers 

2 - P - capitated specialists 

Note: only 0 will be valid for phase I. 

pcr_calc_nbr 

smaliint 

Unique identifier to indicate the formula to use when calculating the 
per amount. Values are validated against codejist table. 

pcr_type 

smaliint 

Indicates if the Physician Contingency Reserve (per , also known as 
withhold, refer to The Managed Care Resource - A Glossary of Terms 
for the definition of PGR) is a percent or flat rate. Valid values are: 

0 - F - flat rate 

1 - P - percent 
default is 0 

pcr_valiie 

float 

Physician Contingency Reserve (PGR) rate, pcrjype indicates if value 
, is a percent or a flat rate. 

per_day_iimit 

smaliint 

Used for limiting the number of units of a procedure covered per day. 
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-^4 


Column Name 

Attributes 

Description 

rerro_flag 

smallint 

Indicates if the rate should be applied to previous days also, or just 

applied to current and future days. Valid values are: 

0 - N - apply to current and future days. 

! - Y - apply to previous days» current day. future days. 

default is 0 

review_date 

datetime 

The date the fee amount was last reviewed and/or changed. 

review_nbr 

smallint 

The review number to apply to claims. This feature is optional and 
should be used with discretion. It implies manual intervention for 
processing of claims. 

rvu 

float 

Relative Value Unit. Introduced by HCFA to reimburse physicians' 
fees based on the amount of time and resources expended in treating 
patients (without adjustments for overhead costs and geographical 
differences). RVUs are seoip at the procedure code level (not the fee 
schedule level). 

surface^flag 

smallint 

Indicates the number of surfaces the procedure can apply to. Used for 
dental procedure codes (proc_code_type = "D"). Valid values are: 
0 - invalid/not required 
1 

2 
3 
4 
5 

thru^code 

char (20) 

The highest value of the data element of a range for the criteria 
defmition. 

tooth_adult_from 

char (2) 

The lowest value of an adult tooth number range. Used for dental 
procedure codes (proc_code_type = "D") to determine if the procedure 
can apply to a specific tooth. 

tooth_adult_thru 

char (2) 

The highest value of an adult tooth number range. Used for dental 
procedure codes (proc_code_type = "D") to determine if the procedure 
can apply to a specific tooth. 

tooth_child_from 

char(l) 

The lowest value of a child tooth number range. Used for dental 
procedure codes (proc_code_type = "D") to determine if the procedure 
can apply to a specific tooth. 

tooth_chi!d_thru 

char(l) 

The highest value of a child tooth number range. Used for dental 
procedure codes (proc_code_type = "D") to determine if the procedure 
can apply to a specific tooth. 

tooth_nbr_flag 

smallint 

Indicates if a tooth number is required when submining a claim with 
the procedure code. Used for dental procedure codes (proc_code_type 
« "D"). Valid values are: 

0 - N . No 

1 - Y - Yes 

tooth_range_flag 

smallint 

Indicates if a tooth range is allowed when submining a claim with the 
procedure code. Used for dental procedure codes (proc_code_type = 
"D"). Valid values are: 

0 - N - No 

1 - Y - Yes 

user^id 

char (15) 

A unique Id for each person or process that insened or modified data in 
the database table. 

usertimestamp 

datetime 

The date and time an update or insert occurred in the database table. 
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We claim: 


1 1, A system including a computer system and a user program for 

2 processing health care transactions in response to a user request in a 

3 heterogeneous, distributed computing network, comprising: 

4 (a) a user interface tier for collecting user inputs and 

5 presenting transaction outputs; 

6 (b) a data access tier for data storage and retrieval, said data 

7 access tier including one or more databases of health care 

8 transaction information; 

9 (c) a transaction logic tier for applying a predetermined set 

10 of transaction procedures to said user inputs and said database of 

11 health care transaction information resulting in transaction output; 

12 (d) an electronic network connecting said user interface 

13 tier to said data access tier and to said transaction logic tier, said data 

14 access tier to said user interface tier and to said transaction logic tier 

15 and said transaction logic tier to said user interface tier and to said 

16 data access tier; and 

17 (e) a communication interface for exchanging health care 

18 transaction information among said user interface tier, said data 

19 access tier and said transaction logic tier along said network, said 

20 communication interface including an interface definition language 

21 generating transaction-specific communication codes whereby data 

22 is exchanged through a common interface structure regardless of the 

23 origin of the data. 

1 2. The system of claim 1 wherein the user program of said user 

2 . interface tier operates in a graphical user interface environment. 

1 3. The system of claim 2 wherein the graphical user interface 


2 environment is consistent with the standards of Windows® operating 

3 system. 
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1 4. The system of claim 1 wherein said databases of said data access tier 

2 are relational databases. 

1 5. The system of claim 4 wherein the relational databases are 

2 organized and accessed using Sybase SQL Server database development 

3 tools. 

1 6. The system of claim 1 wherein said transaction procedures of said 

2 transaction logic tier are developed using ANSI C and SQL programming 

3 languages. 

1 7. The system of claim 1 further including one or more functional 

2 subsystems connected to the electronic network, each subsystem including 

3 said user interface tier, said data access tier, said transaction logic tier and 

4 said communication interface. 

18. A method for processing health care transactions in response to a 

2 user request in a heterogeneous, distributed computing network, said 

3 network including a user interface tier having a computer system and user 

4 program, a data access tier including one or more databases of health care 

5 transaction information, a transaction logic tier including a predetermined 

6 set of transaction procedures, comprising the computer-implemented steps 

7 of: 

8 (a) initiating a transaction in response to user request; 

9 (b) generating transaction-specific communication codes 

10 according to a predetermined common interface structure; 

11 (c) appending the communication codes to the 

12 transaction information; and 

13 (d) transferring health care transaction information 

14 among said user interface tier, said data access tier and said 

15 transaction logic tier to generate transaction output. 


a? 
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1 9. The method of claim 8 wherein step (b) is implemented by using 

2 Open Environment corporation's Entera programming model for creating 

3 remote procedure calls. 

1 10. The method of claim 8 step (d) further including the computer- 

2 implemented steps of: 

3 (dl) processing said health care transaction information in 

4 said transaction logic tier to generate transaction 

5 output; 

6 (d2) generating transaction-specific server communication 

7 code in response to transaction output created; 

8 (d3) appending server communication code to transaction 

9 output. 

1 11. The method of claim 8 further including the computer- 

2 implemented step of: 

3 (e) providing transaction output to user. 


1 12. The method of claim 11 v^herein step (e) is implemented by 

2 displaying the transaction output to said user via a computer monitor. 

1 13. The method of claim 11 wherein step (e) is implemented by 

2 presenting the transaction output to said user via a printer. 

1 14. The method of claim 11 wherein step (e) is implemented by 

2 presenting the transaction output to said user via electronic mail. 

1 . 15. The method of claim 11 wherein step (e) is implemented by 

2 presenting the transaction output to said user via facsimile machine. 
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Fig. lA 
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Fig. 16 


wo 98/35284 


3/11 


PCTAJS98/02372 
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malnO 
{ 

result B member lookup"^ 
} 


client program \ q, 


DCE Interface Definition Language 


interface enrollment { 
int memberjookup{ 

[in] Int member_no, 
(out) char member named:): 

} 
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Fig. 5 
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<fPrbcedureX:ddes: 


^Type: |a) ± ) Jlode: (10040 ACNE SURGERY-- 


Procedure Codes 


RVU 


Fee Guer,' 


. — ^Typei C 

-EfTcctive Date: 01/01/1996 


Code: 10040 


Expiration Date: j3l/12/2093 


-Description: f^cFlisURGERY 

Gender Limit: C Male C Female (• Ncne 

0 Age Less Than: | TiS 


Age Greater Than: | 

Description Required: f 


■ Dental Procedures-T^ 


Tooth number Required: f 
Tooth Range Allowed: f" 


:*;::'y';' surface Flag: |0 i*[ 
Adutt Range: • 
Child Range: j - 


1 of 1 
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File Edit View Window (jclp 
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Search CrrterU: Procedure Code List 
Procedure Type; (C |±| 


' "'"Procedure Code: [lOOOO 
' Procedure Description: | 


Through: (12000 


Auto Close T^c 


Search 


Clear 


Procedure 
Type Code 


Description 


Effectiue 
Date 


c 
c 
c 
c 
c 
c 

6 of 113 


10080 

DRAINAGE OF PILOrnDAL CYST 

01/01/1996 

looai 

DRAJNAGE OF PILONIDAL CYST 

01 All /1 935 

10120 

REMOVE FOREIGN BODY 

01A3in996 

10121 

REMOVE FOREICM BODY 

01A3in996 

10140 

INQSION * DRAINAGE OF HEMATOMA. S 01^T3in996 

10160 

PUNCTURE DRAINAGE OF LESION 

01A31/19S6 

J 

V 



Select 


' Close .i 
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1 ^V' 
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File- Edit View Window Help 


EH 


Proct 
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F*t Sch 

HCit 
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PCon 

HCon 
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□ Con 
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S«t-up 


Help 

01^ 


Sort 
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: vProcedureXddesY 


'Type: !■: l*| >CQde: [10040 AC^E SURGERY.,-- ' 


Procedure Codes 


RNAJ 


Fee Query 


Contract 

Unit..-'' 


Fee 
Schedule 


Effective 
Date 


NYH 

. nyh' 
Km 

NYH 
IvT/H 
SHC 
1 of 20 


- 1 . 

.1000, 
5000 
5DC0 •: 

. 5900 
5901 ' 
9000 ■ 

soon 

S002 


,01/01/1995 
01A3S/1934 
01A]1/t9SG 
01/01/1995 
01^6/1994 
Q1A3S/1994 

. 01A36/1994 
01A36/1994 
01AJ6/1994 
01/01/1993 
01/05/1995 


Expfrotion X 
Date / 

31/12/1995 
31/12/2099 
31/12/2099 
3in2/1995 
31/12/2099 
31/12/2099 
31/12/2099 
31/12/2093 
31/12/2099 
31/12/1999 
31/12/2099 


Fee Max 


Factor 


12345678,900 
• 72.130 
0 

- 67.890 
60.260 
.57.680 
75.320 

■ 72.130 
72;J50 
90.000 
5.0C0 


1.0C0 
1.000 
1.000 
1,000 
1.000 
1,000 
1.000 
1.0C0 
1.000 
1.000 
1.000 
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